1. Field
This disclosure is generally related to Content Centric Networks. More specifically, this disclosure is related to a security component of a transport stack that verifies a Content Object on behalf of an application.
2. Related Art
The proliferation of mobile computing and cellular networks is making digital content more mobile than ever before. People can use their smartphones to generate content, to consume content, or even to provide Internet access to other computing devices that generate or consume content. Oftentimes, a device's network location can change as a person takes this device to a new physical location. This can make it difficult to communicate with this device under a traditional computer network (e.g., the Internet) when the device's new network location is not known.
To solve this problem, information centric network (ICN) architectures have been designed to facilitate accessing digital content based on its name, regardless of the content's physical or network location. Content centric networking (CCN) is one example of an ICN. Unlike traditional networking, such as Internet Protocol (IP) networks where packets are forwarded based on an address for an end-point, the CCN architecture assigns a routable name to content itself so the that content can be retrieved from any device that hosts the content.
A typical CCN architecture forwards two types of packets: Interests and Content Objects. Interests include a name for a piece of named data, and serve as a request for the piece of named data. Content Objects, on the other hand, typically include a payload, and are only forwarded along a network path that has been traversed by an Interest with a matching name, and traverse this path in the reverse direction taken by the Interest packet. Typical CCN architectures only send Content Objects as a response to an Interest packet; Content Objects are not sent unsolicited.
CCN architectures can ensure content authenticity by allowing publishers to sign content, which allows consumers to verify content signatures. However, typical CCN routers do not perform content signature verification on Content Objects to avoid incurring additional network latency. Some CCN routers also maintain a Content Store that caches content to minimize the round-trip-delay, by returning a cached Content Object whenever possible. However, content caching in routers opens the door for denial-of-service (DoS) attacks.
One such DoS attack involves content poisoning, where an adversary injects fake content into a router's cache to flood the CCN network with fake content that blocks access to legitimate content of the same name. Applications can avoid becoming victim to content poisoning attacks by enforcing the use of self-certifying content names, or by verifying that the returned Content Objects is signed by a trusted entity. However, this is only possible if the application knows the content's hash value ahead of time, or has access to a set of digital certificates that bind the Content Object to a trusted entity. Implementing client applications that enforce CCN security measures can increase the complexity of client applications, which can require the application's developer or local user to maintain an up-to-date set of trusted root certificates that can be used to verify Content Objects. Hence, implementing client applications that enforce CCN security measures can require significant development costs and on-going maintenance costs for the developer and the user.